本章目標

這一章要做的不是一張「看起來可以報名」的表單，而是一個真的能協助台灣小型營隊處理招生的 MVP。完成後，你會有：

• 手機優先的課程與梯次頁面。
• 家長與學員報名流程。
• 名額、截止日期與候補規則。
• 工作人員可使用的報名後台。
• 不會把家長個資公開出去的資料權限。

第 23 章會沿用同一個專案加入綠界付款、LINE 通知與對帳。本章先把報名這件事做對，不要同時把金流、發票、接送、保險與 CRM 全塞進第一版。

為什麼這一章重要

很多台灣營隊仍用 Google 表單收件，再由工作人員把資料貼到試算表、人工計算剩餘名額、逐一通知家長。這套流程在只有十筆報名時還能運作，到了熱門梯次就會出現幾個典型問題：

• 表單額滿後仍能送出。
• 同一位學員被重複登記。
• 家長不知道自己是正取、候補還是尚未確認。
• 工作人員修改試算表時誤刪資料。
• 為了方便作業，所有人都拿到完整家長名單。

我們以「台北一間兒童程式營隊」為例。它有三種課程、六個暑期梯次，每梯次 12 人，由兩位工作人員管理。第一版的成功標準很具體：家長能在手機上完成報名，額滿後自動進入候補，工作人員能確認與取消報名，而且任何家長都不能讀到別人的資料。

思考模型：報名不是表單，是名額狀態機

表單只負責收資料，招生系統真正要管理的是狀態：

可報名 -> 待確認 -> 已確認
                \-> 已取消

額滿 -> 候補 -> 遞補待確認 -> 已確認

同時還有三個會影響名額的條件：梯次容量、報名截止時間、有效報名數量。不能在前端顯示「剩 1 位」後，就相信兩個同時按下送出的使用者只會有一個成功。最後一個名額必須由資料庫交易或後端函式原子化判斷。

這一章採用以下規則：

• pending 與 confirmed 都占名額。
• waitlisted、cancelled 不占名額。
• 額滿後的新報名自動成為 waitlisted。
• 工作人員取消一筆有效報名後，只提示下一位候補可遞補，不直接把人改成已確認。
• 同一位學員不可重複報名同一梯次。

開始之前

你需要一個 Lovable 專案，以及 Lovable Cloud 或 Supabase 後端。介面使用繁體中文，時間統一採 Asia/Taipei。示範資料使用虛構姓名與手機號碼，不要拿真實兒童資料測試。

先在 Plan Mode 貼上這段需求：

我要為台北的小型兒童程式營隊建立招生系統。
請先規劃，不要修改程式。

使用者有訪客、家長、工作人員與管理者。公開頁面要顯示課程、梯次日期、地點、適合年級、價格與剩餘名額。家長可填寫聯絡人姓名、台灣手機、Email、學員姓名、年級與必要備註。

每梯次有容量與報名截止時間。pending 和 confirmed 占名額；額滿後的新報名為 waitlisted。相同學員不可重複報同一梯次。公開使用者不能讀取任何其他家長或學員資料。

請提出資料模型、狀態流程、權限矩陣、避免最後一個名額超賣的方法，以及分階段建置與驗收計畫。第一版不要加入付款、接送、病歷或 CRM。

先檢查計畫有沒有把「剩餘名額」當成前端可自行修改的欄位。如果有，要求 Lovable 改成由有效報名計算，並把最終判斷放在後端。

圖 22-1：從全新專案以 Plan Mode 產生資料模型、角色與權限規劃；確認內容後才按 Approve 進入 Build。

步驟 1：建立課程與梯次資料

建立五張核心表：

• programs：name、slug、summary、grade_min、grade_max、is_published。
• sessions：program_id、starts_on、ends_on、location、capacity、registration_deadline、status。
• guardians：user_id、name、phone、email。
• children：guardian_id、name、grade、note。
• registrations：session_id、child_id、status、created_at、confirmed_at、cancelled_at。

金額即使本章尚未付款，也建議用新台幣整數儲存，例如 price_twd = 6800，不要用浮點數。日期在資料庫可用標準日期或 UTC 時間，顯示時明確轉成台北時間。

請先建立三個測試梯次：尚有名額、只剩一位、已額滿。這比一開始只放一個空梯次更容易驗證畫面狀態。

步驟 2：先做手機版公開招生頁

家長多半從 LINE 或社群連結打開招生頁，因此先以窄螢幕完成：

• 課程卡片顯示適合年級與簡短成果。
• 梯次列出日期、星期、地點、價格與狀態。
• 剩餘名額低於 3 人時才顯示具體數字。
• 額滿時按鈕改為「登記候補」，截止後不可送出。
• 每個表單欄位都要有可見標籤，不只使用 placeholder。

圖 22-2：Lovable 完成資料層與公開瀏覽後的桌面版首頁，三種示範課程直接讀取 Cloud 資料。

圖 22-3：切換 Mobile view 驗證標題、導覽與課程卡片在窄螢幕下仍能閱讀。

梯次畫面必須同時證明不同狀態，而不是只截最好看的成功情境：

圖 22-4：Python 梯次已過截止時間，狀態徽章與按鈕都顯示「已截止」。

圖 22-5：同一課程同時呈現已截止與尚有名額梯次，讓家長清楚選擇可報名梯次。

提示詞可以這樣寫：

請先完成營隊公開招生頁，不要建立後台。
以 390px 寬度的手機畫面為優先，顯示三種課程與六個梯次。
每個梯次要顯示台北時間的日期、星期、地點、適合年級、價格與報名狀態。
尚有名額顯示「立即報名」；額滿顯示「登記候補」；截止或停招時停用按鈕並說明原因。
不要在前端寫死剩餘名額，資料必須來自後端查詢。
完成後用桌面與手機預覽檢查資訊層級和按鈕狀態。

步驟 3：設計最小必要報名資料

報名表分成「家長聯絡資料」與「學員資料」。手機接受 09xxxxxxxx，儲存前移除空白與連字號；Email 做基本格式檢查。學員年級使用選單，避免自由文字產生「小三、三年級、3」三種資料。

圖 22-6：從開放梯次開啟手機版報名表，欄位包含家長、手機、Email、學員、年級與選填備註。

備註欄旁要直接說明：「請勿填寫病歷、身分證字號或其他非報名必要的敏感資料。」若未來真的需要過敏或緊急醫療資訊，應另外評估蒐集目的、保存期限、存取人員與事件處理流程，不能順手塞進一般備註。

送出前顯示個資用途摘要與同意勾選。它不是法律文件的替代品，但能讓使用者知道資料會用於聯絡、名額管理與行前通知。

步驟 4：把名額判斷放到後端

建立一個後端操作 create_registration。它必須在同一次可信任操作中：

1. 檢查梯次仍開放且未逾截止時間。
2. 檢查同一學員是否已有非取消報名。
3. 鎖定或以資料庫安全方式取得目前有效報名數。
4. 尚有容量則建立 pending，否則建立 waitlisted。
5. 回傳報名編號與狀態，不回傳其他人的資料。

不要讓瀏覽器先查剩餘一位，再直接寫入 pending。這會在同時報名時超賣。也不要讓表單傳入 status=confirmed；新報名的狀態由後端決定。

步驟 5：建立成功、候補與失敗狀態

送出成功後不要只顯示綠色勾勾。畫面至少包含：

• 報名編號。
• 課程與梯次。
• 目前是待確認或候補。
• 接下來會透過哪個管道聯絡。
• 使用者現在不需要重複送出的提醒。

圖 22-7：使用虛構資料實際送出報名後，Cloud 寫入成功並顯示明確的後續聯絡方式。

接著用容量只有 1 人的測試梯次驗證最後名額。第一筆報名由後端判定為 pending，成功頁再從資料庫查回報名編號、課程、日期與狀態，而不是直接相信網址參數。

圖 22-8：最後一個有效名額寫入成功；畫面同時提醒家長不要重複送出。

重新整理梯次頁後，容量 1 的梯次已切換成「額滿・可候補」，操作按鈕也改為「加入候補」。

圖 22-9：名額狀態來自後端結果，額滿後仍保留清楚的候補入口。

再用另一位虛構學員送出，系統回傳 waitlisted 並顯示候補順位 1，證明第二筆沒有擠進有效名額。

圖 22-10：第二筆報名進入候補，而不是讓容量為 1 的梯次超賣。

可能失敗的情況包括截止時間剛到、同一學員已報名、連線中斷與後端暫時無法使用。錯誤文案應讓家長知道下一步，不要把資料庫錯誤原文顯示出來。

步驟 6：建立工作人員後台

後台首頁顯示今日新增、各梯次確認人數、待確認數與候補數。工作人員可以依梯次篩選、查看單筆資料、確認、取消與匯出必要欄位。

權限至少分成：

角色不能由使用者自行寫入 profile。請用受保護的 membership 或 role 資料，並用 RLS（Row Level Security，列層級安全）或等效後端規則強制執行。

步驟 7：處理取消與候補遞補

取消有效報名後，系統找出最早建立的候補者，顯示為「可邀請遞補」。第一版不自動改成 confirmed，因為家長可能已安排其他活動。工作人員發出邀請後，將狀態改成待確認並設定回覆期限；逾期再輪到下一位。

提示詞：

請新增取消與候補遞補流程。
取消 pending 或 confirmed 報名後釋放名額，列出建立時間最早的 waitlisted 報名供工作人員邀請。
不要直接把候補者改成 confirmed；先改成 pending 並記錄回覆期限。
每次狀態變更要保存操作者、舊狀態、新狀態、時間與原因。
請補上未授權、重複操作及兩位工作人員同時遞補的防護與測試。

步驟 8：建立驗證矩陣

至少用家長 A、家長 B、工作人員與管理者四個帳號測試：

1. 家長 A 可建立並查看自己的報名。
2. 家長 A 無法用網址或 API 讀取家長 B 的資料。
3. 兩人同時搶最後一個名額，只能一人進入有效名額，另一人候補。
4. 同一學員重複送出不會建立兩筆有效報名。
5. 額滿、截止與停招梯次的畫面與後端都拒絕一般報名。
6. 工作人員可確認報名，但不能修改容量或提升自己的角色。
7. 取消後名額與候補順序正確。
8. 手機重新整理成功頁不會重複建立報名。

請讓 Lovable 先列出證據再修正：

請驗證營隊報名 MVP，不要先假設功能正常。
使用兩個家長帳號、工作人員與管理者測試權限矩陣，並模擬兩筆請求競爭最後一個名額。
檢查重複報名、截止時間、候補遞補、取消與重新整理。
逐項列出操作、預期結果、實際結果與證據；有失敗時先說明根因，再提出最小修正。

實作練習

建立「暑期 Python 冒險營」三個梯次：

• A 梯：容量 12，目前 8 人。
• B 梯：容量 1，目前 0 人，用於競爭測試。
• C 梯：容量 12，狀態為已截止。

再建立兩位家長、三位學員、一位工作人員。完成報名、重複送出、最後名額競爭、取消與候補邀請。預期成果是家長端能清楚理解狀態，後台數字與資料一致，而且跨帳號查詢被拒絕。

常見錯誤

用前端數字當名額真相

前端顯示只供參考，最終名額必須在後端建立報名時重新判斷。

把候補當成已錄取

候補不應占名額，也不應在未取得家長確認前自動變成已確認。

所有人共用管理者帳號

這會失去責任追蹤。每位工作人員應使用自己的帳號與最小必要權限。

收集過多兒童資料

第一版不需要身分證、病歷、完整生日與家庭資訊。每多一個欄位，都增加保管責任。

只測一個帳號

權限問題必須用至少兩個不同家長帳號才測得出來。

上線前檢查清單

• [ ] 梯次容量、截止時間與狀態由後端判斷。
• [ ] 最後一個名額的並行測試通過。
• [ ] 重複報名有資料庫或後端防護。
• [ ] 家長只能讀取自己的資料。
• [ ] 工作人員與管理者權限不同。
• [ ] 備註欄提醒不要填敏感資料。
• [ ] 取消、候補與遞補都有事件紀錄。
• [ ] 桌面與手機流程均已驗證。
• [ ] 測試資料不含真實兒童個資。
• [ ] 正式環境已提供隱私說明與聯絡管道。

延伸閱讀

• Lovable Cloud
• Supabase integration
• Lovable security
• Supabase Row Level Security

名詞解釋與延伸提問

• 容量（capacity）：一個梯次最多可接受的有效報名數。
• 並行競爭（race condition）：兩個操作同時讀到相同舊狀態，因而做出互相衝突的更新。
• 冪等（idempotency）：相同操作重複執行，最終仍只產生一次有效結果。
• RLS：由資料庫依登入者與資料列規則限制讀寫。

你可以接著問 Lovable：「請依我的營隊容量、候補期限與人員角色，改寫本章的狀態流程與驗證矩陣。」下一章會讓這套報名系統真正收款，並處理付款成功但通知失敗、重複回傳與人工對帳。

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：

📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！

🎁 免費送 Lovable 額度給讀者！

我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！